Sentry Rust SDK: sentry-tower
Adds support for automatic hub binding for each request received by the Tower server (or client, though usefulness is limited in this case).
This allows breadcrumbs collected during the request handling to land in a specific hub, and avoid having them mixed across requests should a new hub be bound at each request.
Examples
use NewSentryLayer;
// Compose a Tower service where each request gets its own Sentry hub
let service = new
.layer
.timeout
.service;
More customization can be achieved through the new
function, such as passing a [Hub
]
directly.
use Hub;
use SentryLayer;
// Create a hub dedicated to web requests
let hub = new;
// Compose a Tower service
let service = new
.layer
.timeout
.service;
The layer can also accept a closure to return a hub depending on the incoming request.
use Hub;
use SentryLayer;
// Compose a Tower service
let hello = new;
let other = new;
let service = new
.layer
.timeout
.service;
When using Tonic, the layer can be used directly by the Tonic stack:
use ;
use NewSentryLayer;
;
builder
.layer
.add_service
.serve
.await?;
Usage with tower-http
The http
feature offers another layer which will attach request details
onto captured events, and optionally start a new performance monitoring
transaction based on the incoming HTTP headers.
The created transaction will automatically use the request URI as its name.
This is sometimes not desirable in case the request URI contains unique IDs
or similar. In this case, users should manually override the transaction name
in the request handler using the Scope::set_transaction
method.
When combining both layers, take care of the ordering of both. For example
with tower::ServiceBuilder
, always define the Hub
layer before the Http
one, like so:
let layer = new
.layer
.layer;
Resources
License: Apache-2.0
- Discord server for project discussions.
- Follow @getsentry on Twitter for updates